1. Field of the Invention
This invention relates to improvements in pipelined computer processors that execute relatively simple instructions in hardware controlled execution units and execute relatively complex instructions in a milli-mode architected state with vertical microcode (i.e. millicode) routines executing in the same hardware controlled execution units. More particularly, this invention relates to a set of specialized millicode instructions which reduce the number of millicode instructions and machine cycles required to perform certain complex operations that are called relatively frequently.
2. Description of the Prior Art
Instruction sets used in computer systems employing so-called Complex Instruction Set Computing (CISC) architecture include both simple instructions (e.g. Load, or Add) and complex instructions (e.g. Program Call, or Load Address Space Parameters). As an example to which the invention has particular relevance, see "IBM Enterprise Systems Architecture/390 Principles of Operation" (Publication Number SA22-7201-02, available from IBM Corporation, Armonk, N.Y.), which is incorporated herein by reference in its entirety. As these computer systems (e.g. IBM System 390) have become more powerful, larger percentages of the instruction set have been implemented using hardware execution units to increase the systems performance. Conventionally, the complex functions are implemented in microcode because building hardware execution units to execute them is expensive and error prone.
Implementing complex functions in microcode provides flexibility to fix problems and expandability in that additional functions can be included later. In certain prior art machines, where much of the processor is hardware controlled, a dedicated microprocessor based execution unit is often provided in order to implement the complex functions. This unit can be microprogrammed to execute complex instructions and complex functions such as handling interrupt conditions.
More recently, prior art proposals have been advanced for machines with a so-called milli-mode operating capability; see, for example, IBM Technical Disclosure Bulletin Vol. 35, No. 4A of September 1992, incorporated herein by reference, and U.S. Pat. Nos. 5,280,593 and 5,226,164 assigned to the assignee of this invention and also incorporated herein by reference.
A milli-mode operation enables implementation of complex functions in a large, hardware controlled, pipelined, general purpose digital computer without a microprocessor. Milli-mode implements these complex functions with the flexibility provided by firmware and avoids a packaging problem introduced by the inclusion of microprocessor hardware. Rather than a microprocessor, milli-mode uses the preexisting dataflow and hardware controlled execution units of a pipelined processor to accomplish complex functions. Additional hardware controlled instructions (private milli-mode only instructions) are added to provide control functions or to improve performance. These private milli-mode instructions augment the architected instruction set. Milli-mode routines can intermingle the milli-mode only instructions with architected instructions to implement complex functions.
Milli-mode detection logic in the instruction decode logic detects the requirement to enter milli-mode, and this causes millicode routines to be fetched. The millicode routines are decoded by the decoder hardware and dispatched for execution in the same way as the architected macro-instructions (system-mode instructions).
Practically all of the architected macro-instructions that are implemented as hardware controlled instructions can be executed in milli-mode. The set of instructions available in milli-mode can be considered to be an alternate architecture that the processor can execute.
The hardware-executed instructions which are valid only for millicode are generally of a format and a function similar to those of ESA/390 instructions. In this way, the unique hardware required to implement these instructions is minimized, and the simplicity of the hardware design is maintained. This simplicity of hardware controls is a chief advantage of millicode over other forms of internal code (e.g. microcode) which require considerably more unique hardware.
A disadvantage of a millicoded design is that some complex operations require more internal code instructions and/or more machine cycles than with some forms of microcode. In some cases, this is due to the inefficiency of the base instruction set (e.g. the hardware-executed ESA/390 instructions) when used to perform these complex operations. Depending on the frequency with which these operations are performed, the impact on overall system performance may be significant.
Specifically, the base instruction set on a millicoded implementation of ESA/390 is not well suited to efficient emulation of the ESA/390 instructions Compare String, Move String, and Search String. The Search String instruction scans a storage operand until it finds a byte (8 bits) with a specified value. The Move String instruction moves bytes from a storage operand to a new storage location until it finds a byte in the source string with a specified value. The Compare String instruction compares two storage operands byte-by-byte until it finds corresponding bytes that are not equal, or until it finds a specified value (usually an end-of-string marker). The Compare String instruction also requires that two operands be compared for byte equality, and that the first instruction-ending condition (byte inequality between the two storage operands, or specified ending byte found in either operand) be identified as if all tests were done on each byte before proceeding to the next byte.
These requirements would be simple to satisfy in a millicode implementation that processed one byte at a time, but that would yield unacceptably long execution times for these instructions. On the other hand, pure hardware implementation of these instructions poses a problem due to the requirements that no bytes of storage appear to be accessed beyond the logical end of each operand. Since the length is not known until the ending character is found, this significantly complicates the hardware operand controls and is not consistent with an overall goal of limiting hardware execution to "simple" operations.
An object of this invention is the provision of special millicode instructions that provide efficient millicoded execution of these string operations with minimal increase in hardware complexity.
Briefly, this invention contemplates the provision of special millicode instructions to accelerate the "inner loop" portion of a millicode routine to execute ESA/390 string instructions. Specifically, these millicode instructions are: Replicate Byte, Find Byte Equal, Find Byte Not Equal, and Compare String Bytes instructions.
The Replicate Byte Double millicode instruction copies the low-order byte from one millicode general register (MGR) into each of the 8 bytes of a MGR pair that includes that MGR.
The Find Byte Equal millicode instruction compares two values byte-by-byte and indicates via a condition code where (if anywhere) corresponding bytes of the two operands are equal. Two forms of the instruction are defined, one in which each operand is 8 bytes long and is contained in an MGR pair, and one in which each operand is 4 bytes long and is contained in an MGR.
The Find Byte Not Equal millicode instruction compares two values byte-by-byte and indicates via a condition code where (if anywhere) corresponding bytes of the two operands are unequal. Two forms of the instruction are defined, one in which each operand is 8 bytes long and is contained in an MGR pair, and one in which each operand is 4 bytes long and is contained in an MGR.
The Compare String Bytes millicode instruction compares three operands, each 8 bytes in length, contained in pairs of MGRs. For each byte, working left to right, the corresponding bytes are compared between each pair of operands (1 vs. 2, 2 vs 3, and 1 vs. 3). If the first and second operands are not equal in that byte, or if either the first or second operand is equal to the third operand in that byte, then the condition code is set to indicate which condition was found and an MGR is set to indicate the byte position in which it occurred.